You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Found this interesting issue when looking into SAPP-1966. The process.exit function in the CLI is monkey patched so we can send telemetry before the process ends. This is fine in all other cases in cli.ts except for when we are checking whether the command is to simply check the version using the --version or -v flag.
I think that this is a bit dangerous to monkey patch process.env especially in a cli environment (the comment remarks this) so I thought I would give it a go to refactor a bit. We could obviously just add a return statement after the process.exit call in question but it seems like a recipe for problems if you go about using process.exit in some other file and assume that your code will stop executing at that point, but it won't.
What to review
Is the approach ok? Happy to just leave the return or go ahead and create some sort of async process.exit() set-up, but it feels the risk is bigger than the reward.
Testing
Added a test, tell me if it is in the wrong place.
efps — editor "frames per second". The number of updates assumed to be possible within a second.
Derived from input latency. efps = 1000 / input_latency
Detailed information
🏠 Reference result
The performance result of sanity@latest
Benchmark
latency
p75
p90
p99
blocking time
test duration
recipe (name)
18ms
20ms
22ms
38ms
0ms
7.1s
recipe (description)
16ms
17ms
19ms
36ms
0ms
4.4s
recipe (instructions)
5ms
6ms
8ms
34ms
0ms
3.1s
synthetic (title)
51ms
52ms
55ms
62ms
164ms
12.6s
synthetic (string inside object)
53ms
56ms
62ms
411ms
791ms
8.2s
🧪 Experiment result
The performance result of this branch
Benchmark
latency
p75
p90
p99
blocking time
test duration
recipe (name)
18ms
20ms
22ms
31ms
0ms
6.7s
recipe (description)
16ms
18ms
20ms
29ms
0ms
4.3s
recipe (instructions)
5ms
6ms
7ms
39ms
0ms
3.1s
synthetic (title)
51ms
53ms
59ms
289ms
534ms
13.3s
synthetic (string inside object)
53ms
57ms
72ms
471ms
898ms
9.0s
📚 Glossary
column definitions
benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
test duration — how long the test run took to complete.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Found this interesting issue when looking into SAPP-1966. The
process.exit
function in the CLI is monkey patched so we can send telemetry before the process ends. This is fine in all other cases incli.ts
except for when we are checking whether the command is to simply check the version using the--version
or-v
flag.I think that this is a bit dangerous to monkey patch
process.env
especially in a cli environment (the comment remarks this) so I thought I would give it a go to refactor a bit. We could obviously just add areturn
statement after theprocess.exit
call in question but it seems like a recipe for problems if you go about usingprocess.exit
in some other file and assume that your code will stop executing at that point, but it won't.What to review
Is the approach ok? Happy to just leave the
return
or go ahead and create some sort ofasync process.exit()
set-up, but it feels the risk is bigger than the reward.Testing
Added a test, tell me if it is in the wrong place.
Notes for release
Not worth it.